Event subscription and notification in network environments is becoming increasingly commonplace and important. Event subscription generally allows a first network entity to subscribe to event notifications from a second entity. Common examples of events include “presence” and “location;” however, the number and types of events are endless. For instance, conventional instant messaging services permit a first user to subscribe to a presence event for a second user. As such, during the period of the subscription, the first user receives updates as to the presence status (e.g., online or offline) of the second user. The subscription may be for a single inquiry, which will return a response of “present” or “not present” for the second user. The subscription may also be for a set period of time, which may result in multiple updates, or for other options (e.g., status change notifications, ongoing notifications, etc.)
Various protocols may be used for event subscription and notification. For example, the Session Initiation Protocol (SIP) may be used for such purposes (see, e.g., IETF request for comment document RFC 3261, entitled: SIP: Session Initiation Protocol, July 2002, the contents of which are hereby incorporated by reference in its entirety). SIP was generally developed to allow for initiating a session between two or more endpoints in the Internet by making these endpoints aware of the session semantics. Accordingly, devices (or users that run certain applications on these devices) are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these endpoints. To achieve this, SIP provides a registration mechanism for devices and users, and it applies mechanisms such as location servers and registrars to route the session invitations appropriately. Although SIP is primarily a tool for initiating a communication session between endpoints, extensions to SIP have been proposed to provide event registration and trigger notification (see e.g., IETF document RFC 3265, SIP-Specific Event Notification, July 2002, the contents of which are hereby incorporated by reference in its entirety). Such a proposal, however, neither specifies the semantics of specific events, nor systems and methods for uploading event information.
The SIP event framework, which would enable event-based information provisioning to any node in the Internet, is supposed to become a key element within the SIP infrastructure. However, the current Internet Engineering Task Force (IETF) standardization process for extensions to the SIP event framework, namely the definition of particular event packages that are required for provisioning of particular information, requires such extensions to run through an extensive process, starting from drafting a proposal to becoming a request for comment (RFC) document. If the usage of the SIP event framework for a large variety of events is envisioned, such a standardization process may soon become a significant bottleneck for the deployment of SIP event-based techniques. Such standardization becomes even more difficult if the usage of SIP events for information provisioning is considered based on some dynamic or ambiguous application semantic. In this regard, the required consensus within the standardization typically heavily delays any deployment of the particular event package. Hence, it seems undesirably difficult to use SIP events for such ambiguous or dynamically determined application semantic.
As a typical scenario, consider the provisioning of location information through SIP events. Apart from bare sensor information, SIP “location” events may be desirable even for derived location information, such as city, county, or state. Further, an application may desire to specify the usage of particular sensors in determining the location information. Hence, it is generally not sufficient to subscribe to some “location” information without having an unambiguous agreement of the semantic of the information that will be provided by the SIP event server.
In another typical scenario, SIP events may be used to provide notifications as to whether or not a particular user is “available,” such as may be used in call routing decisions. The semantic of “available,” however, is typically dependant upon several factors. The decision whether or not a device or a user is available may consider one or more different inputs, such as schedule and location, schedule only, connectivity of certain devices, presence of other users, current activity, and/or status of particular sensors (e.g., a tilt sensor on the phone may indicate that a mobile station has been placed face down to thereby reject calls). Furthermore, the semantic may also depend upon the current situation of the user. For example, “available” may be differently defined in private situations compared to business situations. Due to the variety of interpretations of the same event, then, it is often desirable to have an unambiguous understanding of the semantic before a subscription before subscribing to a respective event.
As a consequence of the extensive standardization process, current SIP events are merely defined for rather simple, non-ambiguous semantics, such as presence. Any more complex application semantic is assumed to be implemented within the SIP client, such as an end user or application, placing the burden of realizing the application semantic on the client. However, it is desirable to enable more complex application semantics even in SIP event servers, e.g., through the implementation of reasoning functionality and rule-based semantics in order to provide more complex, semantic-rich information through SIP events. Placing such functionality in the SIP event server may be advantageous due to the fact that the SIP event server may have better computational power and memory to implement the functionality. Also, the SIP event server may have better (or even exclusive) access to resources that are required to implement the desired application semantic. In addition, through the consistent re-use of particular semantics, the cost of the entire service may be reduced.